disaster recovery plan [English]
InterPARES Definition
n. ~ Policies and procedures that guide recovery from a major interruption of ordinary operations caused by a variety of natural or human-caused accidents or catastrophes.
Other Definitions
- SAA Glossary 2005 (†241 s.v. "business continuation and disaster recovery plan"): The procedures necessary to resume operations after an atypical disruption of routine activities.
- SAA Glossary 2005 (†241 s.v. "disaster plan"): Policies, procedures, and information that direct the appropriate actions to recover from and mitigate the impact of an unexpected interruption of operations, whether natural or man-made.
- Wikipedia (†387 s.v. disaster recovery plan): A disaster recovery plan (DRP) is a documented process or set of procedures to recover and protect a business IT infrastructure in the event of a disaster. Such plan, ordinarily documented in written form, specifies procedures an organization is to follow in the event of a disaster. It is "a comprehensive statement of consistent actions to be taken before, during and after a disaster." The disaster could be natural, environmental or man-made.
- Wikipedia (†387 s.v. DRP (disaster recovery planning)): Planning to ensure the timely recovery of information technology assets and services following a catastrophe, such as fire, flood or hardware failure.
Citations
- Bradbury 2008 (†674 p.14): Creating and testing a disaster recovery plan is one of the key elements of business continuity management. Traditionally business continuity and disaster recovery (DR) planning have always been separated between the business and the information technology (IT) departments, but it has long been recognised that this "divide" creates more problems than it solves. After all, most businesses could not continue to operate successfully if their IT services were unavailable for a period of time. The recent launch of BS 25999 has established a Business Continuity Management (BCM) standard which intrinsically links BCM, Incident Management and IT DR. Essentially the key message is that to have true business continuity, you must also have strong IT DR capability. A disaster recovery plan should interface with the overall business continuity management plan. In the case of both, it's important to be clear and concise, to focus on the key activities required to recover the critical IT services, and to test, review and update on a regular basis. (†1542)
- CNSS-4009 (†730 p.25): Management policy and procedures used to guide an enterprise response to a major loss of enterprise capability or damage to its facilities. The DRP is the second plan needed by the enterprise risk managers and is used when the enterprise must recover (at its original facilities) from a loss of capability over a period of hours or days. (†1727)
- Hawkins, et al. 2000 (†676 ): Preparing a disaster recovery plan is not a solitary effort. It requires the expertise, ingenuity, and cooperation of corporate employees and top-level decision makers. A well-planned DRP requires three main functional areas (management, information technology, and human resources) to participate and prepare themselves for subjects such as employee awareness, and safety of computer technology and data security. (†1545)
- Hawkins, et al. 2000 (†676 ): The Business Recovery Plan is the document used to assist an organization in recovering its business functions. A Disaster Recovery Plan (DRP), however, is a document designed to assist an organization in recovering from data losses and restoring data assets. A DRP should be a pro-active document, a living and breathing document. It does not document the tasks, it is an action plan that is used to identify a set of policies, procedures, and resources that are used to monitor and maintain corporate information technology (IT) before, during, and after the disaster. (†1546)
- Widmer 2010 (†675 p.40): Risk managers need to consider simplicity in all realms of disaster recovery planning. The more complicated the process, the more chances there are that something will go wrong. "Measure complexity by how many systems are involved and how many separate systems and vendors are involved," said Rodriguez. "If there are a lot of parties, each one with their own systems and procedures, your IT department [will have] to coordinate." (†1544)